I'm pretty confused about this. Is it correct that prior to this MR that when ExitCodeExceptions are constructed they never have anything in their eceStdout and eceStderr? That is, there's only one place where one is created, and there those fields are set to empty?

What is the point of those fields then? And what's the use case for populating them?

This may need @snoyberg to opine.

Ah, I got this wrong — documentation on which functions include stdout/stderr was actually added by my CTO in #22! I didn't notice because it uses the record update syntax so my grep didn't turn it up:

Please rebase on master to pick up some CI fixes.

Done, PTAL

I'll have to defer to @snoyberg on this. I don't really understand the possible consequences.

I don't see anything concerning here myself. No objection to a merge, is there something in particular you were concerned with @tomjaguarpaw?

I didn't feel comfortable approving myself because I'm not familiar with STM, and also because there is a large range of points in the design space where we should slot in something like this. For example, instead considering these as "creating a value of type ExitCodeException" we could consider them as alternatives to waitExitCode that return ExitCodeExceptions instead of ExitCodes. Alternatively we could just add something slightly different, like

runProcessExitCodeException :: MonadIO m => ProcessConfig stdin stdout stderr -> m ExitCodeException

as a counterpart to runProcess.

Anyway, if you're happy with it then let's go ahead and merge.

This has been released in https://hackage.haskell.org/package/typed-process-0.2.12.0